RunWay 2.0: the dashboard in Way.Shell - #4

Requests to the dashboard's API are strict: unknown fields and missing non-nullable values return 400.

NuGet audit warnings are errors, as in the other Kododo libraries.

RunWay.Storage.Tests only holds base classes for the PostgreSQL and SQL Server tests.

The dashboard is a Way.Shell module: layout, theme, language, API client and
session handling come from the shell, and UseRunWayDashboard() mounts it with
MapWay. Outside Development the dashboard answers 403 until the host calls
RequireAuthorization() or AllowAnonymous() on what UseRunWayDashboard()
returns. MUI 7 -> 9, Vite 7 -> 8, MUI X Data Grid 9 and Lab 9 pre-releases.

EF Core 10 is not binary compatible with code built against EF Core 8
(ExecuteUpdate's SetPropertyCalls is gone), so an app on EF Core 10 could not
run RunWay. EF Core and Npgsql now follow the target framework (8, 9, 10);
RunWay.SqlServer references the patched System.Security.Cryptography.Pkcs.
On EF Core 10, RunWay.SqlServer sends lists as one JSON parameter, as EF Core
8 and 9 do: one parameter per item gave a plan that deadlocks runners polling
for jobs with runners updating them.

recharts, MUI X Data Grid and Lab were in the dashboard's module, which every
page waited for. They now load with the page that uses them: way.js goes from
266 to 7 KB after gzip.

Pages of jobs without a sorting were unordered, and jobs with equal values in
the sorted field could move between pages; the id now comes last. The two
relationships between jobs and recurrences are configured explicitly instead
of with [ForeignKey] on both navigations, which EF Core warned about. The
model is unchanged.

-p:UseLocalWayShell=true still builds against ../WayShell.